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INTRODUZIONE 

ARM è una architettura RISC di grandissimo successo. Oltre il 95% di telefoni mobili e tablet 
impiegano un processore ARM (c'è chi dice il 99% degli smartphone). La quantità di dispositivi 
venduti è altissima, tanto che c'è chi ha osservato che i dispositivi ARM sembrano essere il 
prodotto di consumo più diffuso al mondo, perfino più della Coca-Cola. Tanto per dare 
un'idea, nel del 2014 sono stati venduti circa 12 miliardi di chip contenenti core ARM; nello 
stesso anno Intel ha venduto circa 400 milioni di processori. Ovviamente si tratta di dispositivi 
di differenti categorie, almeno per quanto riguarda la massa delle vendite. La società ARM, 
titolare della proprietà intellettuale, ricava da ogni dispositivo venduto qualche penny, Intel 
ricava decine o centinaia di dollari. Nel 2015 il numero di chip contenenti core ARM è salito 
a circa 15 miliardi (fonte Wikipedia). Gli ARM vengono usati dove di richiedono bassi costi 
e bassi consumi. Normalmente essi trovano impiego nei sistemi embedded. Nondimeno, dal 


2016, AMD produce un processore orientato al mercato dei server, che integra 8 core ARM 
a 64 bit. 


Questa appendice illustra anche l'architettura dei microcontrollori AVR, dispositivi RISC che 
pure godono di grande successo nel settore dei sistemi embedded. Le ben note schede Arduino 
si basano su di essi. 


Infine, si coglie l'opportunità per illustrate il funzionamento dei coprocessori convenzionali. 
Data la chiarezza della soluzione adottata nell'architettura ARM per l'impiego dei coproces- 
sori, ad essa ci si riferisce. 


1Si veda all’indirizzo https://www.bloomberg.com/news/articles/2014-02-04/arm-chips-are-the-most- 
used-consumer-product-dot-where-s-the-money 
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ARCHITETTURA ARM 


E.1 Introduzione 


La sigla ARM oggi viene interpretata come Advanced RISC Machine. In realtà la 
sigla originariamente significava Acorn RISC Machine, dove Acorn era il nome di una 
società inglese, nata nel 1978, costruttrice di calcolatori (PC) che, nel 1983, decise di 
progettare una propria architettura. La ditta aveva costruito in precedenza un PC basato 
sulla CPU 6502, quella utilizzata nei primi Apple. Il PC si chiamava BBC, come la 
nota rete televisiva inglese che in una serie di trasmissioni aveva indagato sul futuro dei 
microprocessor computers allora al loro esordio — si era infatti negli anni settanta del secolo 
scorso e i calcolatori all’epoca erano grosse macchine racchiuse in armadi voluminosi — 
promovendo lo sviluppo di PC indirizzati sostanzialmente a un impiego didattico. Il BBC, 
come il primo Apple e il Sinclair, aveva la forma di una voluminosa tastiera al cui interno 
si trovava la logica di macchina e alla quale si poteva collegare un monitor (non grafico) e 
altri dispositivi, come le unità a cassette (analogiche). Ovviamente non disponeva e non 
era prevista la possibilità di avere un disco rigido. 

Nel seguito, Acorn decise di passare a una CPU più potente del 6502. All’epoca co- 
minciava ad affermarsi 1’8086 e in particolare il PC IBM che sarebbe poi diventato lo 
standard nel calcolo personale. La Acorn, non trovando adeguate per i suoi obiettivi le 
CPU di mercato, ed essendo venuta a conoscenza della ricerca svolta a Berkeley, dove il 
progetto RISC 1 (praticamente sviluppato nel contesto di un corso universitario) aveva 
dimostrato che era possibile costruire processori molto semplici, ma di prestazioni com- 
parabili con quelle delle macchine CISC , decise nell’imbarcarsi nella produzione di un 
suo processore RISC. 

Ufficialmente il progetto venne lanciato nel 1983. La prima versione (oggi conosciuta 
come versione v1) ebbe luce nel 1985. Il dispositivo integrava 25.000 transistori e aveva 
prestazioni pari, se non superiori, a quelle dell’80286 apparso qualche anno prima, che 
però integrava ben 134.000 transistori. Era la prima macchina RISC ad essere immessa 
sul mercato. Nelle versioni successive il numero di transistori si posizionerà in zona 35.000 
(stiamo naturalmente parlando di dispositivi che non integrano la cache, la quale avrà 
l’effetto di far crescere di un ordine di grandezza il conto dei transistori). 

ARM è nata come architettura a 32 bit. La versione v1 aveva un bus indirizzi a 26 bit, 
che resterà tale anche nella versione v2 (1987) e che sarà portato a 32 bit con la versio- 
ne v3. Con versione v2 venne introdotto il supporto per i coprocessori. Successivamente 
sono state molte altre evoluzioni. Tra le estensioni meritevoli di essere rammentate c’è il 
cosiddetto repertorio “Thumb”, introdotto con la versione v4, che fa lavorare la macchina 
a 16 bit (in alternativa a 32, che però resta il funzionamento di base), conferendo com- 
pattezza al codice. L'estensione “Jazelle” è in grado di eseguire codice Java in formato 
“byte-code”. Inutile dire che nel tempo i processori sono stati dotati di cache, di gestione 
della memoria virtuale, mentre il parallelismo è stato portato a 64 bit per alcuni modelli 
di CPU. Attualmente (inizi 2017) L’architettura è alla versione v8. 

Si evidenzia che le denominazioni di ARM tendono a generare una certa confusione. 
Bisogna distinguere tra “famiglia”, “architettura” e “dispositivo” (o core). Ad esempio: le 
famiglie ARM6 e ARM7 si basano sulla versione v3 dell’architettura; la famiglia Cortex 
(da cui è stato derivato il processore A4, usato da Apple) si basa sulla versione v7 
dell’architettura. 
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Determinante per l’affermarsi dell’architettura ARM fu la scelta di Apple di utiliz- 
zarla nel 1990, nel PDA da essa prodotto denominato Newton. Apple, Acorn e VLSI 
Technology svilupparono assieme la famiglia ARM6 (basata sulla versione v3 dell’archi- 
tettura) usata in Newton. Le tre società si legarono in una compartecipazione aziendale. 
Venne mantenuta la sigla ARM, ma la nuova azienda si chiamò “Advanced Risc Ma- 
chines Ltd”. Venne ridefinito il suo modo di operare: da produttore di PC a licenziante 
tecnologie. 

Dalla seconda metà del 2016 ARM è proprietà di una compagnia di telecomunicazioni 
giapponese. 


Essenzialmente ARM sta sul mercato vendendo tecnologia. Essa possiede la proprietà 
intellettuale dell’architettura e cede il suo uso in licenza agli effettivi produttori (tra questi 
Intel, Texas Instrument, Samsung, Apple e altre rinomatissime società). In particolare la 
Apple Computers ha collaborato nella definizione del processore ARM6. Nella primavera 
2010, Apple ha introdotto l’iPad; questo dispositivo impiega il processore A4, una versione 
dell’ARM Cortex-A9 prodotto da Samsung per Apple. Lo stesso dispositivo è stato usato 
nell'iPhone 4. L’iPhone 7 impiega un SoC, sviluppato specificatamente da Apple, che 
comprende 4 core ARM a 64 bit (architettura v8), di cui due ad alte prestazioni e due a 
prestazioni più basse. 

Nel campo della progettazione elettronica si designa come semiconductor Intellectual- 
ly Property (IP) core, o più semplicemente IP-core, un blocco di logica riusabile o uno 
schema di logica riusabile, proprietà intellettuale di chi lo ha definito o progettato. Gli 
IP-core vengono usati come componenti nella progettazione di dispositivi ASIC o FPGA. 
Sebbene vi siano molte società attive nel campo degli IP-core, la ARM fa la parte del 
leone: nel 2013 essa si prendeva il 43,2% del mercato (fonte Wikipedia). 

La caratteristica principale dell’architettura ARM è che il core del processore è estre- 
mamente semplice confrontato con quelli dei processori di uso generale di grande diffu- 
sione. Rispetto a questi ultimi, i processori ARM contengono un numero di transistori 
molto più basso, che li rendono fabbricabili a costi ridotti, lasciando libera sul chip un’a- 
rea utilizzabile per implementare specifiche funzionalità. Ogni costruttore è messo nella 
condizione di produrre un processore ARM arricchito delle funzionalità che mirano a 
specifiche applicazioni. 

Dalla semplicità derivano anche bassi consumi. Tanto per dare un’idea, il processore 
PXA255 (facente parte della famiglia XScale sviluppata da Intel a partire dalla versione 
v5 dell’architettura ARM) a 400MHz fornisce prestazioni comparabili con quelle di un 
Pentium II a 300MHz, ma consumando 50 volte meno energia. Per questi motivi i pro- 
cessori ARM sono predominanti nelle applicazioni embedded e, in particolare, in quelle 
dove il basso consumo è un requisito primario, come per esempio nella telefonia mobile. 

Non si creda che ARM sviluppi solo processori per telefonini o per impieghi dove sono 
richieste relativamente basse potenze di calcolo. La gamma corrente (2017) dei processori 
comprende dispositivi a 64 bit (retrocompatibili con quelli a 32). La società AMD, la stesa 
che produce processori x 86, ha iniziato a produrre processori basati su architettura ARM; 
in particolare, il processore denominato Opteron A1100, integra ben 8 core ARM-Cortex- 
A5T a 64 bit. Il SoC contiene integrati altri sottosistemi come controllori di memoria, 
controllori PCIe, SATA, UART e altro. Il fatto che sia stato denominato “Opteron”, la 
linea di maggiori prestazioni di AMD, lascia intendere quale sia il livello delle prestazioni 
offerte dall’A1100 indicativo delle sue caratteristiche. 

AI fine di facilitare l’impiego dei suoi prodotto nei SoC, è stato definito un bus de- 
nominato Advanced Microcontroller Bus Architecture (AMBA) che, nelle ultime versioni 
prevede una gerarchia di bus, che possono essere sfruttati a seconda delle necessità (per 
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dispositivi relativamente lenti e/o per dispositivi molto veloci). Le specifiche AMBA sono 
aperte. In pratica, il bus è uno standard industriale. 

Chi fosse interessato ad approfondire gli aspetti appena accennati non ha che da fare 
una ricerca in Internet, dove si trova una messe di informazioni sull’architettura ARM. 

Visto il gran numero di versioni, famiglie e dispositivi ARM, questo documento non 
pretende in alcun modo di essere esaustivo, né, tantomeno, fornire informazioni puntuali 
che richiederebbero lo studio degli specifici modelli. Verranno solo illustrati gli aspetti 
caratteristici dell’architettura, facendo essenzialmente riferimento alle versioni di base. 
In particolare prenderemo come campione il modello ARM7 TDMI?, un processore di 
architettura v4, introdotto nel 1994, che ha goduto di grande diffusione. 


E.2 Caratteristiche generali 
ARM è una architettura RISC; come tale essa presenta 


e un numero consistente di registri di CPU; 

e operazioni di solo load e store rispetto alla memoria; 

e operazioni di manipolazione dei dati esclusivamente tra registri di CPU; 

e formati istruzioni con campi in posizione e di misura fissi, per facilitare la decodifica; 
tutte le istruzioni sono su 32 bit; 

e esecuzione condizionata di quasi tutte le istruzioni del repertorio; 

e modalità indirizzamento autoincrement e autodecrement. 


Importante è la possibilità di collegare coprocessori. Ciò consente ai produttori di 
dispositivi e/o apparati di sviluppare estensioni orientate a specifici campi applicativi 
realizzate come coprocessori (ad esempio, per un produttore di telefoni mobili può essere 
conveniente sviluppare un proprio DSP, Digital Signal Processing). 

Per quanto si riferisce alla densità del codice, a partire dal 1996 è stato definita una 
modalità di funzionamento detta Thumb, da riguardare come un superstato. In questo 
stato la macchina esegue un repertorio di istruzioni — il repertorio Thumb - in cui le 
istruzioni sono codificate su 16 bit. I registri di CPU restano a 32 bit ma diminuiscono 
di numero. Il modo di funzionamento Thumb può essere intrecciato con il normale mo- 
do ARM. Ci sono situazioni (come per esempio rispondere alle eccezioni) in cui, se la 
macchina è in modo Thumb, essa passa automaticamente al modo ARM. 

Alcuni modelli prevedono l’estensione Jazelle, attraverso la quale la macchina esegue 
direttamente il byte code dei programmi java. Lo scopo è evidente, rendere possibile l’e- 
secuzione di programmi java su macchine a basso consumo come si richiede nei dispositivi 
portatili. 

Alcuni modelli hanno una interfaccia di debug che consente di collegare direttamente 
la CPU a un apparato di debugging e controllare da quello l’esecuzione dei programmi. 


E.2.1 Modello di programmazione 


Prima di passare a illustrare il modello di programmazione, è necessario anticipare che 
l’architettura ARM ha 7 modalità (modes) operative che sono: User, System, FIQ (fast 
interrupt), Supervisor, Abort, IRQ (interrupt) e Undefined, come illustrato in Figura E.1. 
La figura illustra sinteticamente il significato dei diversi modi. 


2TDMI sta per: Thumb, Debug, Multiply, fast Interrupt 
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Delle 7 modalità, 5 corrispondono al servizio delle eccezioni. Nella terminologia ARM 
il termine “eccezioni” viene come nel libro si usa il termine “interruzioni”; ovvero un’ec- 
cezione può essere determinata da un malfunzionamento (Undef), da un’interruzione 
esterna (IRQ) o da una trappola o interruzione software (SVC). 

Il modo System è stata introdotta a partire dalla versione v4. 

Ogni modo operativo ha accesso a un differente sottoinsieme di registri e a un diffe- 
rente stack, come spiegato più avanti. Escluso lo User, i restanti modi sono privilegiati; 
alcune istruzioni possono essere eseguite solo nei modi privilegiati. 


Description 


Supervisor Entered on reset and when a Software Interrupt 
(SVC) instruction (SWI) is executed 


Entered when a high priority (fast) interrupt is 


FIQ raised 


Entered when a low priority (normal) interrupt 
is raised 


Exception modes 


Used to handle memory access violations 


Used to handle undefined instructions 


System Privileged mode using the same registers as 
User mode 
U Mode under which most Applications / OS Unprivileged 
ser 
tasks run mode 


Figura E.1 Modalità operative dei processori ARM. La figura è riportata direttamente dalla 
documentazione ARM 


La CPU dispone complessivamente di 37 registri* (Figure E.2 e E.3) organizzati come 
segue. 


e 16 registri da 32 bit denominati R0-R15 


— RO-R12 sono registri di uso generale; 
— R13 viene usualmente usato come Stack Pointer (SP), ma l’architettura non forza il 
suo impiego in tal senso; 
R14 ha la funzione (architetturale) di subroutine Link Register (LR). In esso la logica 
salva l’indirizzo di ritorno (ovvero il contenuto del registro R15 —vedi sotto) quando 
viene eseguita l’istruzione BL (Branch and Link) o al servizio di una interruzione; 
— R15 ha la funzione architetturale di Program Counter (PC); 
I tre registri R13, R14, R15 possono comunque essere manipolati come registri di uso 
generale, per cui, per esempio, un salto può essere ottenuto anche con una istruzione 
che carichi il registro R15 con l’indirizzo di destinazione. 


e Un registro di stato CPSR (Current Program Status Register), corrispondente a quella 
che nel libro è stata denominata PSW. Il contenuto e il formato di questo registro sono 
riportati in Figura E.3 


3Alcuni modelli recenti ne prevedono un numero maggiore. In questo documento ci riferiamo 
sostanzialmente al dispositivo ARM7TDMI (versione v4 dell’architettura). 
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System and User Supervisor Undefined 


12 
Re] 
N 


dI 


n PO 


ARM state program status registers 


CPSR CPSR CPSR CPSR CPSR CPSR 
I SPSR_fq [N SPSR_svo [N SPSR_abit | SPSR_irq | IN SPSR_und 


N = banked register 


Figura E.2 Modello di programmazione dell’architettura ARM 


4 bit esprimono altrettante condizioni (Negative, Carry, Zero e oVerflow); 

il bit T distingue tra due (super)modalità di funzionamento: quella usuale, denomi- 
nata ARM di cui si sta parlando e la modalità Thumb di cui la macchina esegue un 
repertorio in cui le istruzioni sono codificate su 16 bit. 

i bit I and F abilitano le interruzioni normali (I) and veloci (F) 

i bit M4-MO identificano il modo di funzionamento. 


20 registri “duplicati” (banked), ovvero privati dello specifico modo operativo. Essi sono 


evidenziati con un triangolo grigio in Figura E.2 e sono specifici dei modi corrispondenti. 
Vengono indicati con il loro nome seguito dall’identificatore del modo, e.g. R13_IRQ. 


Tutte e cinque le modalità di eccezione hanno duplicati i registri R13, R14 e SPSR; 


il modo FIQ ha anche la duplicazione dei registri R8-R12. Quando c’è un passaggio ad 
un differente modo, per esempio da User a IRQ, mentre i registri non duplicati restano 
immutati, per R13, R14 e SPSR entrano in funzione i duplicati. Lo scopo dei registri 
duplicati è evidente: 


e Nel registro SPSR_m di modo m, la logica del processore salva automaticamente lo 
stato di macchina esistente prima di passare al modo m; ovvero, viene salvata la parola 
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di stato che si aveva prima di passare al servizio della corrispondente eccezione. 

e I registri R13 e R14 consentono di passare al modo m senza doversi preoccupare di 
salvare i registri R13 (SP) e R14 (LR) del contesto di provenienza. In modo m la 
macchina usa R13_m e R14_m (ovvero SP_m e LR_m). In altre parole, ciascun 
modo usa un suo stack pointer (R13_m) e tiene traccia dell’indirizzo di provenienza 
nel suo registro di link (R14_m). 


Condition 
code flags Reserved Control bits 
| 
Î LIPARI IL | 
31 30 29 28 27 26 25 24 23 8 7 65 4 3 2 10 
TTI 


N|IZ|IC|V]e]e]e[ele{/ } F | T |M4|M3|M2|M1|M0 


L Overflow L Mode bits 
Carry or borrow or extend State bit 


Zero FIQ disable 
Negative or less than IRQ disable 


Figura E.3 Formato del registro di stato CPSR. 


Vale la pena di osservare che PC è, sostanzialmente, un registro come un altro e 
pertanto su di esso si fanno le usuali operazioni tra registri. C’è da dire che l’assemblatore 
riconosce il simbolo PC come r15 e, similmente, il simbolo LR come r14 e SP come R13. 

La chiamata di sottoprogramma si effettua con l’istruzione BL (Branch and Link); 
essa salva l’indirizzo di ritorno (PCpr+4) in r14. Per tornate al chiamante si può sem- 
plicemente copiare il contenuto di r14 in r15 


MOV r15,r14 
meglio ancora si può usare la forma più espressiva riconosciuta dall’assemblatore 
MOV PC,LR 


Sono disponibili istruzioni che prelevano da/salvano su lo stack. In particolare ci sono 
le istruzioni LDM/STM (Load Multiple/Store Multiple) che rispettivamente estraggono 
dalle/depositano sulle posizioni di testa dello stack copiando in/da una lista di registri. 
Ad esempio 


STMFD sp!,r0-r7,LR 


memorizza ordinatamente il contenuto dei registri da r0 a r7 e r14 nello stack, a partire 
dalla posizione puntata da r134. 

Si noti che ARM, diversamente da molte architettura RISC, prevede istruzioni per la 
gestione dello stack (uno per ciascuna modalità di funzionamento, Figura E.1). Lo stack 
viene controllato semplicemente attraverso il registro R13. 


4STMFD, Store Multiple Full Decrement, assume che lo stack sia gestito decrementando in modo 
automatico (di 4) dopo ogni scrittura il contenuto di sp. 
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E.3 Repertorio istruzioni 


L’architettura ARM è tipicamente load/store, ovvero l’accesso alla memoria avviene 
sono per queste due istruzioni. La manipolazione dei dati avviene unicamente nei registri. 
Per essere una macchina RISC le modalità di indirizzamento sono più dell’usuale e il 
numero di formati è cospicuo, come illustrato dalla Figura E.4, ma si noterà che i formati 
sono tali da rendere la decodifica semplice. 


31 30 29 28 27 26 25 24 23 22 21 20 191817 16151413 1211109 87 6543210 


Data processing and 
FSR transfer Cond 001 Opcode 


nce Pit 


Multiply long Cond 0/0|0/0|1U/A 


Single data swap Cond 0|0|0|/1|0 


Branch and exchange Cond 0/0|0|1|0 


Halfword data transfer, 
register offset Cond o0|oPU 


Halfword data transfer, 
immediate offset Cond o|0|0/PU 


Single data transfer Cond 0|1/1/P|U 


Undefined Cond 0|1/1 1 


Block data transfer Cond 1|0 Register list 


Branch Cond 1|0 


Coprocessor data 
transfer Cond 1|1 


Coprocessor data 
operation Cond 1/1 


Coprocessor register 
transfer Cond 1|1 


Software interupt| Cond 1|1|1/1 Ignored by processor 


31 30 29 28 27 26 25 24 23 22 21 20 191817 161514 131211109 876543210 


Figura E.4 Formato istruzioni del repertorio ARM. (Figura riportata direttamente dalla 
documentazione ARM.) 


Esecuzione condizionale 

Una caratteristica che contraddistingue il repertorio ARM è l’esecuzione condizionale. 
A tale scopo i primi 4 bit di ogni istruzione contengono una condizione e l’istruzione 
viene eseguita solo se la condizione coincide con quella data dai 4 bit di condizione della 
parola di stato, indicati come Condition Code Flags in Figura E.3. Esiste tuttavia la 
possibilità di far eseguire le istruzioni in modo non condizionato. A tale scopo uno dei 16 
possibili valori della condizione ( precisamente “1110”) è riservato per indicare alla logica 
che l’istruzione deve essere eseguita incondizionatamente. Il fatto che le istruzioni siano 
condizionate o meno si esprime con differenti mnemonici in linguaggio assembler. 
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Code Suffix Flags Meaning 

0000 EQ Z set equal 

0001 NE | Z clear not equal 

0010 CS | C set unsigned higher or same 
0011 CC | C clear unsigned lower 

0100 MI | Nset negative 

0101 PL N clear positive or zero 

0110 VS V set overflow 

0111 VC V clear no overflow 

1000 HI C set and Z clear unsigned higher 

1001 LS C clear or Z set unsigned lower or same 
1010 GE N equals V greater or equal 

1011 Ep N not equal to V less than 

1100 GT Z clear AND (N equals V) greater than 

1101 E Z set OR (N not equal to V) less than or equal 

1110 AL | (ignored) always 


Figura E.5 Codici condizionali. La seconda colonna fornisce il suffisso da aggiungere al codice di 
istruzione (non condizionale) per avere l'istruzione condizionata; la terza colonna dice su quali flag di 
condizione di CPSR (Figura E.3) viene valutata la condizione. il codice 1111 è riservato e non deve 


essere usato. 


Prendiamo ad esempio l’istruzione di salto. Essa ha due codici mnemonici: B per 
Branch e BL per Branch and Link. Il formato dell’istruzione è in Figura E.6. Ai due 
codici può essere attaccato un qualunque suffisso di Figura E.5, ottenendo, ad esempio, 
BEQ, BLNE, BOS, ... 


31 


25 24 


[=] 


fee fed se 


Do, Link bit 


0 = Branch 
4 = Branch with Link 


Condition field 


Figura E.6 Formato dell'istruzione di salto. 


Si noti che un’istruzione condizionale equivale a una istruzione NOP (no operation) se 
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la condizione non è verificata. In pratica, essa viene eseguita come una normale istruzione, 
ma i suoi eventuali effetti hanno luogo solo se la condizione è verificata”. 


L’estensione Thumb, non possiede l’esecuzione condizionale. 


Esempio —____________________ 
Per mostrare quanto possa essere vantaggiosa l’esecuzione condizionale, consideriamo 
l’algoritmo di Euclide per il calcolo del MCD. L'algoritmo è riportato in Figura E.7. Esso 
assume che all’avvio in r0 e rl ci siano già i due numeri di cui si vuole calcolare il MCD. 

In Figura E.8 viene mostrato il programma nella versione con istruzioni non con- 
dizionali, scritto nel linguaggio assembler di ARM. Il tratto di programma Figura E.8 
può essere riscritto usando le istruzioni condizionali come in Figura E.9. Si noti che lo 
mnemonico della sottrazione (sub) assume due differenti forme (subgt e sublt) condizio- 
nali. L’assemblatore provvede a costruire l’istruzione di sottrazione con il corrispondente 
campo condizionale; la prima ha effetto solo se vale la condizione gt (greater than), la 
seconda solo se vale la condizione lt (less than). 


Figura E.7 Algoritmo di Euclide per il calcolo del massimo comun divisore. 


5Si faccia un confronto con l’esecuzione condizionale dell’Itanium (Appendice D), dove le istruzioni 
come le due sopra vengon impaccate per essere eseguite in parallelo, ma solo quella che rispetta la 
condizione ha effetto. 
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MCD cmp r0, ri ;raggiunta la fine? 
beq FINE 
blt Minore ; if r0 > ri salta 
sub r0, r0, ri ir0 <- r0-r1 
bu MCD ;altro giro (branch) 
Minore sub ri, ri, r0Q srl <- r1i-r0 
bu MCD ;altro giro (branch) 
FINE 


Figura E.8 Algoritmo di Euclide con istruzioni incondizionate. 


MCD cmp ro, ri sif r0 > rl 
subgt r0, ro, ri ;i rO <- r0-ri 
sublt ri, rl, r0 jelse rl <- r1-r0 
bne MCD ;raggiunta la fine?} 


Figura E.9 Algoritmo di Euclide con le istruzioni condizionali. 


E.4 Trattamento delle eccezioni 


Quando si manifesta un’eccezione, il processore si porta nel modo m corrispondente 


all’eccezione, effettuando le azioni seguenti: 


viene salvato lo stato corrente di macchina nel registro CPSR del modo m; ovvero 
SPSR_m <- CPSR; 

vengono modificati i bit di CPSR portandoli a riflettere il nuovo modo e, se del caso, 
vengono disabilitate le interruzioni; 

l’indirizzo di ritorno viene memorizzato in LR_m; 

viene copiato in PC l’indirizzo del vettore dell’eccezione. Il vettore di deve contenere 
un’istruzione di salto in modo da passare al corrispondente erception handler. I vettori 
di interruzione sono riportati in Tabella E.1. 


Per tornare al programma interrotto, l’exception handler: 


ripristina CPSR da SPSR_m; 
ripristina PC da LR_m. 


Esempio —_________________ 
L’eccezione di Reset ha l’effetto di: (1) passare al modo Supervisor; (2) disabilitare le 
interruzioni normali e le veloci (portando ad uno i due bit I e F di CPSR); (3) azzerare 
il bit T di CPSR (equivale a riportare la macchina in stato ARM, affermando non è più 
in stato Thumb, qualora ci fosse stata); (4) forzare il PC a eseguire l’istruzione in 0x00. 
Dopo il reset, il contenuto di tutti i registri eccetto PC e CPSR è indeterminato. 


Esempio 
L'istruzione SWI (Software Interrupt) ha pure l’effetto di portare la macchina in modo 
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Indirizzo Eccezione Modo di arrivo CPSR.I CPSR.F 
00 H Reset Supervisore 1 1 
04 H Istr. non definita Indefinito I F 
08 H Interruzione software Supervisore 1 F 
OC H Abort (fetch) Abort I F 
10H Abort (dati) Abort I F 
14H Riservato Riservata - - 
18H IRQ IRQ 1 F 
ICH FIQ FIQ 1 1 


Tabella E.1 Tabella dei vettori di interruzione. La terza colonna rappresenta la modalità di arrivo al 
verificarsi dell'eccezione in seconda colonna, sempre che questa si possa manifestare in base al modo 
corrente. La quarta e quinta colonna rappresentano lo stato dei bit | e F del CPSR (Figura E.3) 
all'entrata nel modo di arrivo. Questi due bit abilitano/disabilitano rispettivamente le interruzioni 
(IRQ) e le interruzioni veloci (FIQ). Su le due colonne di destra un 1 equivale a “disabilitata” (Figu- 
ra E.11), mentre | o F stanno a indicare che i rispettivi bit non cambiano, cioè non vengono influenzati 
dall'eccezione. 


Supervisore. Nelle versioni più recenti dell’architettura l’istruzione si chiama SVC (Super- 
Visor Call). Essa ha un campo immediato di 24 bit in cui è scritto il numero di funzione 
del supervisore che si intende chiamare, come illustrato in Figura E.10. L’handler di SVC 
deve leggere il codice dell’istruzione, in modo da poter per estrarre il campo IMM24 e 
passare alla funzione appropriata. Per stimolare la curiosità del lettore, mostriamo come 
ciò possa essere fatto. 


Cond I abi IMM24 


Figura E.10 Formato dell'istruzione SVC (precedentemente denominata SWI). 


All’inizio dell’handler ci saranno queste istruzioni 


LDR RO, [LR,#-4] ; RO <- codice della SVC eseguita 
BIC RO,R0,#0xf£000000 ; isola i 24 bit a destra (BIt Clear) 


la prima mette nel registro RO il contenuto della parola puntata da R14_sve (LR_sve 
diminuito di 4, punta all’istruzione che ha chiamato; l’effetto è quindi quello di caricare 
in RO il codice completo dell’istruzione. La seconda (BIC sta per Bit Clear) azzera gli 8 
bit più significativi in RO, isolando in tal modo i 24 bit contenenti il numero di funzione 
da svolgere; si tratta ora di fare un salto alla locazione da cui parte la funzione. A tale 
scopo R0 può essere usato come indice in una tabella in cui stanno gli indirizzi delle fun- 
zioni del supervisore; l’indirizzo selezionato può essere caricato in un registro, attraverso 
il quale fare un salto (indiretto) alla funzione. 
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Il ritorno dall’handler di SVC si effettua eseguendo l’istruzione MOVS PC,R14 avente 
l’effetto di portare in PC il contenuto del registro R14_svc e di portare in CPSR il con- 
tenuto di SPSR_ sve. 


Con riferimento alla Tabella E.1 si osservi che quando il sistema va in modo Super- 
visore per effetto di una SVC, le interruzioni vengono disabilitate, mentre lo stato delle 
interruzioni veloci è immutato. Ovvero, se il sistema resta in modo Supervisore, passano 
solo le interruzioni veloci (FIQ). 

Per quanto si riferisce a queste ultime, vale la pena di mettere in evidenza che si 
tratta di interruzioni per le quali presumibilmente bastano poche istruzioni per trattarle. 
Per esempio si consideri il trasferimento da (verso) un periferico a (da) un buffer in 
memoria di blocco di byte. Ad ogni interruzione, si tratta essenzialmente di aggiornare 
un puntatore e un contatore, oltre, naturalmente, a effettuare il trasferimento del byte 
corrente. Queste funzioni accessorie possono essere fatte con un paio di registri. Si capisce 
allora il motivo per cui nel modo FIG siano stati previsti i registri banked R8-R12. I registri 
banked permettono di evitare il salvataggio dei pochi registri che verrebbero utilizzati, in 
tal modo rendendo il servizio delle interruzioni FIQ molto vicino a trasferimenti DM AS. 
In Figura E.11 viene schematizzato il tipico collegamento di un controllore esterno di 
interruzioni a un core ARM. 


ARM core 


IRO 


Controllore IR1 


interruzioni 


IRn 


Figura E.11 Schema tipico per la vettorizzazione delle interruzioni esterne nell’architettura ARM. 


Priorità eccezioni 

Quando due eccezioni arrivano assieme esse sono discriminate in base alla loro priorità, 
come in Tabella E.2. Alcune eccezioni non possono manifestarsi assieme (per esempio 
non è possibile che l’eccezione dovuta all’istruzione SWI si possa manifestare assieme 
all’eccezione per istruzione non definita!). 


E.4.1 Gestore delle interruzioni 


Esaminiamo un aspetto interessante che spiega il motivo per cui c'è uno modo Sy- 
stem, apparentemente identico al modo User. A tale scopo consideriamo il problema della 


6Per curiosità, il vecchio, glorioso Z80 (prima metà anni ’70) disponeva di un meccanismo analogo. 
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Priorità Tipo di eccezione 


1 Reset (priorità massima) 

2 Abort dati (per indirizzamento illegale di un dato) 

3 FIQ 

4 IRQ 

5 Abort fetch (per indirizzamento illegale di un’istruzione) 
6 

7 


Codice di istruzione illegale 


SVC (priorità minima) 


Tabella E.2 Priorità delle eccezioni ARM. Più piccolo il numero più alta la priorità. 


nidificazione dell interruzioni (nested interrupts). 


Su un’interruzione esterna la logica di CPU: 


a) copia CPSR nello SPSR_irq; 
b) modifica appropriatamente i bit di CPSR in modo da indicare lo il modo “igr” e da 


disabilitare il sistema di interruzione (ponendo a 1 il bit I); 


c) memorizza l’indirizzo di ritorno in LR_irq (r14_irq); (d) copia in PC l’indirizzo del 


vettore di interruzione, dove deve trovarsi il salto al gestore delle interruzioni. 


Le interruzioni possono essere gestite in modo “una alla volta” oppure in modo 


nidificato. 


Gestione non rientrante 

In questo caso, il gestore delle interruzioni non riabilita il sistema di interruzione fino al 
termine, in guisa che che ulteriori, eventuali richieste di interruzione abbiano effetto. I 
passi della routine di servizio dell’interruzione sono quelli qui descritti. 


L 


Vengono salvati i registri che verranno toccati dalla routine. Ad esempio, supponendo 
che la routine usi i registri da r0 a r5 il loro salvataggio sullo stack, si fa scrivendo 
STMFD p!,{r0-r5,lr}. L’istruzione in questione è un multiple store e salva nello stack 
(ovviamente del modo “irq”) i registri r0, rl, ..,r5, oltre che il registro lr (ovvero r14_irq 
dove si trova l’indirizzo a cui tornare al termine della routine di servizio). Avendo salvato 
r14 questo può essere usato nella routine, e verrà certamente usato se dall’interno della 
routine si usa l’istruzione BL. 


. Viene identificata la specifica interruzione e viene effettuato il salto al ramo corrispon- 


dente di codice. Questo richiede la lettura del mondo esterno per capire quale IRQ; ha 
effettivamente interrotto, utilizzando il valore di è come indice in una tabella di salto. 


. Conclusa l’elaborazione, vengono ripristinati i registri del programma interrotto e 


il CPSR. Per quanto si riferisce alla prima parte basta eseguire l’istruzione LDMFD 
p!.,{r0-r5,1r}, duale della precedente, il cui effetto è ovvio. Per quanto si riferisce 
al ristabilimento di CPSR, occorrerebbe copiarci il contenuto si SPSR (tralasciamo le 
due istruzioni che servono). 


. A questo punto, poiché lr contiene l’indirizzo di ritorno, basterebbe scrivere MOV 


pe,lf. 


Lo schema precedente ha un problema. Quando CPSR viene ripristinato (punto 3), viene 
riabilitato il sistema di interruzione (se c’è stata un’interruzione vuol dire che il sistema 
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era abilitato). Ma allora, se c’è una richiesta di interruzione non servita, questa si manife- 
sta immediatamente, prima che sia eseguita l’istruzione del punto 4, con ciò distruggendo 
l'indirizzo di ritorno che si trova in r14_irq. È evidente che per rimediare bisogna rendere 
indivisibili le operazioni del punto 3 e 4. Fortunatamente l’architettura prevede che l’i- 
struzione LDM possa, in aggiunta al ripristino dei registri come sopra, anche ripristinare 
allo stesso tempo CPSR. A livello di assembler ciò si ottiene attraverso il qualificato- 
re “°” posto in coda al testo dell’istruzione. Cioè scrivendo LDMFD p!,{r0-r5,pc}"®. 
L’istruzione ha ora l’effetto di: 


a) ristabilire il contenuto dei registri r0-r5; 

b) portare in pc l’indirizzo di ritorno salvato; 

c) aggiornare CPSR con SPSR_irq (cioè con la parola di stato salvata al momento 
dell’interruzione). 


In altre parole, l’istruzione LDMFD p!,{r0-r5,pc}® svolge da sola le funzionalità dei 
punti 3 e 4. 


Interruzioni nidificate 

Le interruzioni nidificate comportano ulteriori difficoltà. Ne diamo qui gli aspetti es- 
senziali, ricordando che per poter consentire la nidificazione delle interruzioni (esterne) 
l’handler associato al modo IRQ deve essere necessariamente rientrante, in quanto le 
interruzioni successive lo possono richiamare mentre è in esecuzione. 

La descrizione che segue assume che la modalità operativa System non esista. 

In aggiunta a quanto descritto in precedenza, nell’interrupt handler oltre ai registri 
manipolati, dovrà essere salvato anche SPSR__irq (se l’handler viene richiamato da al- 
tra interruzione SPSR._irq deve essere al sicuro in quanto il registro in questione viene 
riscritto dalla nuova interruzione). Il funzionamento dell’handler è il seguente: 


e vengono salvati i registri manipolati e SPSR__irq; 

e viene essere azzerata la richiesta di interruzione (IR_i) che ha determinato l’interruzio- 
ne (e che si sta servendo); ciò comporta ovviamente la lettura/scrittura del sottosistema 
di i/0; 

e viene riabilitato il sistema di interruzione; 

* viene effettuata l'elaborazione richiesta dall’interruzione (IR__i) che si sta servendo; (se 
nel frattempo si manifesta un’altra interruzione (IR_j), essendo il sistema di interru- 
zione abilitato, essa andrà soggetta al trattamento ora descritto); 

e a conclusione della elaborazione richiesta dalla specifica interruzione che in quel mo- 
mento è in servizio (potrebbe essere una interruzione nidificata) viene disabilitato il 
sistema di interruzione, riportandosi a una condizione analoga al caso dell’interruzione 
non rientrante; 

e la gestione dell’interruzione si chiude con il ripristino dei registri e dello lo stato si 
macchina in modo indivisibile, come discusso al termine del paragrafo E.4.1. Se era in 
servizio una interruzione nidificata viene ristabilito lo stato di macchina che essa ha 
trovato, ovvero quello del servizio dell’interruzione che questa ha sopravanzato. 


Il precedente schema ha un problema. Se il codice relativo all’elaborazione richiesta dal- 
l'interruzione contiene l’istruzione BL, questa modifica r14_irq; dunque un’interruzione 
che arrivasse immediatamente dopo l’istruzione BL farebbe perdere l’indirizzo di ritorno, 
in quanto riscriverebbe lo stesso r14_irq. La questione ammette due soluzioni: 


e non si usa l’istruzione BL nel tratto di codice dell’handler funzionante a sistema di 
interruzione abilitato; 
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e prima di riabilitare il sistema di interruzione ci si porta nello stato User. 


Ovviamente la prima soluzione è troppo restrittiva. La seconda comporta che il codice 
della routine di servizio viene eseguito in stato User e che, prima di concludere, occorre 
riportarsi al modo IRQ, disabilitando ancora il sistema di interruzione in modo da ripor- 
tarsi alla situazione descritta sopra prima di eseguire l’istruzione di uscita. In questo caso 
l’eventuale BL scrive in r14_user, per cui se arriva un’altra interruzione il suo contenuto 
non è perso. 


La tecnica appena descritta è quella usata fino alla versione v4 dell’architettura, quan- 
do non era previsto il modo System. Il modo User ha una limitazione, esso non consente 
l'esecuzione di certe istruzioni “privilegiate” (in pratica quelle che vanno a modificare 
direttamente lo stato di macchina). Una routine di interruzione potrebbe richiedere l’uso 
di tali istruzioni. Per questo, a partire dalla versione v4 è stato aggiunto il modo System, 
che coincide sostanzialmente col modo user, salvo il fatto di consentire l’uso di istruzioni 
privilegiate. Ne consegue che il precedente ragionamento deve essere modificato nel senso 
di portare la macchina in modo System (non User) dal modo IRQ quando si intende 
riabilitare il sistema di interruzione, rendendo possibile la nidificazione delle interruzioni 
esterne. 


E.5 La pipeline 

Si fa riferimento alla pipeline del modello ARM7-TDMI, che per lungo tempo è stato 
il modello più usato. 

La pipeline in questione è a 3 stadi (Fetch-Decode-Execute). Il suo funzionamento è 
illustrato in Figura E.12. Lo schema di figura si applica alle istruzioni di manipolazione 


dei dati: nel terzo periodo di clock viene effettuata l’operazione e depositato il risultato 
(nel registro di destinazione). 


î fetch 
2 decode 
3 fetch decode 


Figura E.12 Schema della pipeline a 3 stadi dell’ARM7TDMI. 


Per le istruzioni che conteplano un accesso alla memoria (load o store) occorrono 4 
cicli, come illustrato in Figura E.13. Come si vede si tratta di una pipeline estremamente 
semplice. 

Le pipeline delle versioni recenti arrivano a 15 stadi per la pipeline interi e oltre 20 
per la pipeline in virsola mobile. 
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1 |fetch ADD| decode 


execute 


2 fetch STR| decode |calc. addr. [ data xfer 

3 fetch ADD decode | execute | 

4 fetch ADD decode | execute 

" fetch ADD| decode | execute 


Figura E.13 Esecuzione in presenza istruzioni che hanno accesso alla memoria. L'istruzione di STR 
(store) richiede due periodi di clock in fase di decodifica, il secondo essendo usato per calcolare 
l'indirizzo; sull'ultimo clock (esecuzione) viene effettuato il trasferimento. 
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ARCHITETTURA AVR 


E.6 | microcontrollori AVR 


AVR è una famiglia di microcontrollori di tipo RISC a 8-bit ad architettura Harvard, 
cioè con separazione di memoria dati da memoria istruzioni. Essi vengono prodotti dalla 
società Atmel” a partire dal 1996. Questi microcontrollori sono stati tra i primi a utilizzare 
una memoria flash interna per il programma, consentendo la sua modifica senza dover 
rimuovere il microcontrollore dalla scheda su cui è montato, velocizzando il processo di 
correzione e messa a punto del codice. Recentemente è stata introdotta una versione a 
32 bit, ma qui ci limiteremo a considerare solo l’architettura a 8 bit3. 

Le schede Arduino montano controllori AVR Atmel. 

Ci sono tre famiglie di AVR, denominate rispettivamente “tinyAVR”, “megaAVR” 
e “XMEGA”, che differiscono tra loro per la dimensione della memoria di programma 
(flash), per il numero di pin di i/o disponibili e per l'ampiezza del repertorio di istruzioni. 
La versione tiny ha una memoria di programma che può arrivare a seconda dei modelli a 
un massimo di 16 KB, mentre la XMEGA parte da 16 fino a 384KB. Anche la memoria 
dati (SRAM) è più o meno grande a seconda del modello. I chip portano integrata anche 
una memoria EEPROM di dimensioni limitate, usata per tenere dati semipermanenti. 
Ovviamente, sia la memoria flash che la EEPROM mantengono il loro contenuto quando 
il dispositivo viene disalimentato. 

In Figura E.14 è riportato uno schema della CPU. Si osservino le tre memorie distinte: 
la flash come memoria di programma, la SRAM come memoria dati e la EEPROM. 
Quest'ultima è in uno spazio dati separato da quello della RAM. Il costruttore indica 
che la memoria flash è riprogrammabile per almeno 10.000 volte, mentre la memoria 
EEPROM è riscrivibile almeno 100.000 volte. 

Le istruzioni del programma occupano una o due parole da 16 bit nella memoria flash, 
metre lo spazio degli indirizzi dei dati è costituito dal file dei registri, dai registri I/O e 
dalla SRAM. Più avanti (vedi Figura E.16) viene esaminata in dettaglio la suddivisione 
di questo spazio. 

Pur essendo macchine RISC, i microcontrollori AVR hanno un repertorio di istruzioni 
abbastanza esteso. Ovviamente, le istruzioni che fanno accesso alla memoria sono solo 
Load e Store. Essi sono dotati di una pipeline lineare a 2 stadi: la prossima istruzione 
viene caricata nel mentre quella corrente viene eseguita. Dispongono di un oscillatore 
interno che permette una velocità di clock da 0 a 20 MHz; alcuni dispositivi raggiungono 
i 32 MHz. Se si escludono le operazioni di moltiplicazione e addizione/sottrazione a 16- 
bit, le operazioni di Load/Store (che richiedono almeno 2 cicli) e i salti, le operazioni sui 
sui registri R0-R31 sono a ciclo singolo di esecuzione. Ovvero, se il processore eseguisse 
solo istruzioni di questo tipo, esso raggiungerebbe 1 MIPS per MHz. 


In Internet si trova una ampia documentazione sui microcontrollori Atmel. Basta portarsi sul sito 
Atmel e cercare i manuali che descrivono il dispositivo di interesse. 

8E? interessante rilevare che viene prodotta una versione di AVR compatibile dal punto di vista dei 
piedini con microcontrollore Intel 8051. Quest’ultimo, esso pure con architettura Harvard, venne intro- 
dotto molto prima, nel 1980, ed è stato ampiamente usato in ambito industriale, sebbene oggi si tende a 
preferire microcontrollori di più recente concezione, come gli AVR. La sostituzione di un 8051 con un AVR 
richiede una programmazione ex-novo, essendo i relativi repertori di istruzioni completamente differenti. 
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Bus Dati 8 bit 


Unità 
interruzioni 


GPR 


(32 da 8 bit) 


| 


Watch dog 
timer 


MCUCR 


FLASH 
(mem. istruz.) 


j 


[el 
n) Linee di 
5 1/0 
o 
È 
È 
Linee di S] 
controllo sa EEPROM 
to] 


Figura E.14 Organizzazione del core di un AVR a 8 bit. La figura si riferisce sostanzialmente al 
modello AT90S8515 della famiglia megaAVR, ma è rappresentativa della famiglia a 8bit. | differenti 
modelli differiscono non solo per le dimensioni delle memoria, ma anche per certi particolari relativi 
all'i/o; per esempio, su alcuni modelli è direttamente disponibile l'interfaccia USB. SREG è il registro 
di stato, ovvero la PSW; SP è il puntatore alla testa dello stack; MCUCR è un registro di controllo, 
di esso fa parte un bit che se asserito permette l'indirizzamento di una RAM esterna al dispositivo. 


E.6.1 Modello di programmazione 
Il modello di programmazione è schematizzato in Figura E.15; esso comprende: 


e 32 registri a 8 bit di tipo uso generale (GPR). Gli ultimi 6, cioè i registri da R26 a R31, 
possono anche essere riguardati come 3 registri da 16 bit (X, Y e Z come indicato in 
Figura E.15). Essi vengono utilizzati per indirizzare in modo indiretto (fino a 64 KB) 
nello spazio dei dati’. 

e il registro PC (Program Counter). Il numero di bit di PC varia a seconda del modello 
(sui dispositivi più piccoli, con solo 4KB di memoria di programma, PC è su 12 bit). 

e il registro SP (Stack Pointer), a 16 bit, per puntare alla testa dello stack. Questo 
registro mappato nello spazio degli indirizzi di i/o all’indirizzo 3Dh. 

* il registro di stato SREG, di 8 bit, mappato nello spazio degli indirizzi di i/o all’indirizzo 
3Fh, contenente indicatori di stato e il bit di abilitazione delle interruzioni (I). 


Registri di uso generale 
Nelle varianti tinyAVR e megaAVR, i registri di uso generale sono mappati come i primi 


°Si deve aggiungere che su certi modelli sono inoltre disponibili i registri di 8 bit (RAMPX, RAMPY, 
RAMPZ, RAMPD e EIND) mappati in SRAM, usati da certe istruzioni che li antepongono agli indirizzi 
a 16 bit per allargare lo spazio degli indirizzi, portandolo a 224. 
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32 indirizzi di memoria (000016-001F16). Tuttavia essi non sono memoria. Nondimeno, essi 
possono essere indirizzati sia nel modo convenzionale (esplicitando il nome del registro), 
sia indirizzando le corrispondenti posizioni di SRAM. 


7 0 SREG 
Ro ENDENOBOS 
RO 


R25 

R26 XL 
R27 XH 
R28 YL 
R29 YH 
R30 ZL 
R31 ZH 


Figura E.15 Modello di programmazione AVR. | registri evidenziati in grigio non sono presenti su tutti 
i modelli. Essi servono ad estendere lo spazio di indirizzamento, in quanto certe istruzioni prevedono 
il loro impiego come estensione (come bit più significativi) dei registri X, Y e Z. Spesso è presente il 
solo RAMPZ. 


Parola si stato 
I bit del registro di stato (SREG) sono: 


e C: Carry. Per il riporto; 

e Z: Zero. Vale 1 quando un risultato aritmetico è zero; 

e N: Negative. Imposta il valore del bit più significativo di un’operazione aritmetica; 

e V: Overflow. Indica la presenza di un overflow per il complemento a 2; 

e S: Sign. N®V e mostra il segno del risultato; 

e H: Half carry. Riporto interno usato per l’aritmetica di tipo BCD; 

e T: Bit copy. Usato per speciali istruzioni di load/store; 

e I: Interrupt. Abilitazione/disabilitazione delle interruzioni. Questo bit viene azzerato 
dalle interruzioni e riportato a 1 dall’istruzione RETI. 


È previsto un consistente numero di istruzioni di salto condizionato, con le quali vengono 
esaminati i primi 6 bit della lista precedente. Ad esempio BRCC (Branch if Carry Cleared) 
fa saltare alla destinazione se il bit C è a zero. Fanno parte del repertorio anche le 
istruzioni di skip; esse fanno saltare la prossima istruzione se la condizione esaminata è 
verificata. Ad esempio SBRC R,b (Skip if Bit in Register Cleared) fa saltare l’istruzione 


che la segue, se il bit b del registro R contiene zero!°. 


Lo stack 
Lo stackpuò essere sistemato ovunque nello spazio di memoria dati; SP deve essere ini- 


10Questo tipo di istruzione, che difficilmente si trova nei repertori RISC, era normale nei minicalcolatori 
degli anni ’70. 
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zializzato prima del suo uso. Lo stack cresce verso le posizioni basse, ovvero SP è de- 
crementato dall’operazione PUSH e incrementato dalla POP (ambedue queste operazioni 
coinvolgono un registro, ovvero depositano/prelevano 8 bit e conseguentemente decre- 
mentano/incrementano di 1 SP). 

Le istruzioni di chiamata dei sottoprogrammi e le interruzioni determinano il salvataggio 
del PC sulla testa dello stack. A seconda del modello e della relativa dimensione massi- 
ma dello spazio di memoria di programma, vengono salvati 2 o 3 byte; le corrispondenti 
istruzioni di ritorno (RET per il ritorno da sottoprogramma e RETI per il ritorno da una 
routine di servizio dell’interruzione) estraggono corrispondentemente 2 o 3 byte. 


Registri di i/o 
Nello spazio della SRAM, a seguire i GPR sono mappati 64 registri di i/o (posizioni 
002016-005F6). Pure questi registri sono distinti dalla SRAM. Essi possono essere indi- 
rizzati direttamente attraverso le due istruzioni di I/O (IN e OUT), oppure come posizioni 
di SRAM. La SRAM effettiva inizia all’indirizzo 006016. 

Nei dispositivi con molte periferiche, i 64 registri di I/O sono seguiti da 160 registri 
di I/O esteso, ma questi sono accessibili solo come I/O memory-mapped (006016-00F F16); 
in questo caso la SRAM parte dall’indirizzo 010016. Si veda la Figura E.16 e la Tabella 
E.3. 


32 registri 00 - 1Fh 


64 registri I/O 20h - 5Fh 
128 registri I/O (estens.)] 60h - FFh 
100h 


SRAM interna 


SRAM esterna 


ret] 


Figura E.16 Spazio della memoria dati con modelli aventi un numero esteso di porte di 1/O. La misura 
della SRAM interna e l'estensione dell’esterna varia da modello a modello. 


Il numero di porte (registri) di I/O varia a seconda della categoria del dispositivo. 
Come ci si deve attendere da un microcontrollore, le porte di I/O sono molto flessibi- 
li. I singoli piedini possono essere programmati per operare in differenti modi (possono 
funzionare come normali input/output digitali, riconoscere fronti di salita o di discesa, 
riconoscere livelli, esportare clock verso l’esterno, e altro). Qui di seguito si illustra bre- 
vemente come una porta viene controllata nel caso di funzionamento come porta digitale 
convenzionale. 

Le porte sono indicate come PORT, (x = A, B, ... 1!). Qui ci riferiamo sostanzialmen- 
te alla porta A. Essa occupa 3 indirizzi: uno per il registro dati (PORTA), all’indirizzo 
1Bh; uno per il Data Direction Register (DDR.A), all’indirizzo 1Ah; uno per PORTA Pin 
Address (PINA), all’indirizzo 19h. 

PORTA e DDRA possono essere letti o scritti; quando viene letta PORTA vengono letti 


MLA, B, .. caratterizzano porte con possibili differenti funzionalità. 
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i valori presenti sui latch della porta. PINA non è un registro esso viene usato solo come 
indirizzo per leggere direttamente i bit presenti sui pin esterni della porta; PINA è di 
sola lettura. 


Spazio dati 
La Figura E.16 mostra la suddivisione dello spazio di memoria per il caso in cui ci sia un 
numero esteso di porte di i/o. Alla figura corrisponde la Tabella E.3 dove sono mostrati 
i dettagli dell’indirizzamento; i registri di i/o sono visibili sia direttamente, sia come 
posizioni di memoria. 

Infine la Tabella E.4 mostra la mappatura di alcuni registri speciali. Essi pure sono 
visibili sia nello spazio diretto di i/o, sia come mappati in memoria. 

La EEPROM ha un suo spazio separato. Essa viene indirizzata attraverso un registro 
un registro speciale (non indicato in Tabella E.4). 


Indirizzo Dati | Indirizzo I/O Contenuto 

0x0000 — 0x001F Registri RO — R31 

0x0020 — 0x003F 0x00 — 0x1F Registri I/O (indirizzabili a bit) 
0x0040 — 0x005F 0x20 — 0x3F | Registri I/O (indirizzabili non a bit)) 
0x0060 — 0x00FF I/O esteso 

0x0100 — 0x —— SRAM interna 


Tabella E.3 Esempio di mappatura in memoria per il caso di i/o esteso. | registri di i/o possono essere 


visti sia direttamente che come mappati in memoria. La colonna “Indirizzo Dati” corrisponde alla vista 
come RAM. 


Registro | Indirizzo I/O | Indirizzo Dati 
SREG 0x3F 0x5F 
SP 0x3E:0x3D 0x5E:0x5D 
EIND 0x3C Ox5C 
RAMPZ 0x3B 0x5B 
MCUCR 0x35 0x55 
PORTA 0x1B 0x3B 
DDRA Ox1A Ox3A 
PINA 0x19 0x39 


Tabella E.4 Indirizzi/mappatura di alcuni registri speciali. 


E.6.2 Indirizzamento dei dati 


L’indirizzamento dei dati può essere: (a) diretto; (b) indiretto. 

L’indirizzamento diretto riguarda l’accesso ai registri, specificati nel codice di istru- 
zione, oppure l’accesso alla RAM specificato attraverso un campo nell’istruzione. Essendo 
le istruzioni su 16 bit (eccetto alcune), restano pochi bit per un eventuale campo indirizzo, 
per cui l’indirizzamenti diretto consente l’accesso a un ristrettissimo spazio di memoria. 

L’indirizzamento indiretto viene attuato attraverso i registri. A tale scopo il modello 
di programmazione comprende i tre registri X, Y e Z da 16 bit, ottenuti accoppiando gli 
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ultimi 6 registri del file GPR (X è dato da R27:R26 , Y da R29:R28 e Z da R31:R30). 
Ad esempio 


LD Rda,Y ;Rd <- M[Y] 
È possibile anche il pre-decremento o il post-incremento, come qui sotto 


LD R1,-X 5K <- X-1, R1 <- M[X] 
ST Z+,R2 sM[Z] <- R2, R2 <- R2+1 


Infine, è anche possibile prevedere uno scostamento s (un numero contenuto in campo 
nell’istruzione) 


LD Rd,Y+s ;Rd <- M[Y+s] 


ma in questo caso non sono consentiti il pre-decremento e il post-incremento. 


E.6.3 Repertorio istruzioni 


Sebbene si tratti di una architettura RISC il repertorio di istruzioni è alquanto ampio. 
Esso è comunque ottenuto con un formato delle istruzioni pittosto elaborato, seppur 
facilemente decodificabile. A titolo di esempio, in Figura E.17 viene mostrato il formato 
di un selezionato numero di istruzioni. 

Si deve rilevare che l’architettura prevede uno stack e un meccanismo di chiama- 
ta/ritorno ai/dai sottoprogrammi del tutto analogo a quello dei tradizionali processori 
RISC. Lo stesso ragionamento di applica al servizio delle interruzioni. Similmente, sono 
previste le due istruzioni IN e OUT che indirizzano direttamente le porte di i/O, in uno 
spazio di i/o distinto dallo spazio SRAM. 

In conclusione, il repertorio di istruzioni, pur essendo quello di una macchina RISC, 
ha alcune similitudini con i repertori CISC; ciò si riflette nei mnemonici di operazione, 
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15114 |13/12/11/10|9/|8|7]6]/5/4/3]/2]/1/)0 Instruction 
0|0|0/0/0/0|/0/0|/0|0|0|/0|0/0|0|0|NOP 


0.0 0|0|0|/r ddddd rrrr AND Rd,Rr 
0|0)|1 ‘o CARS: ddddd rrre EOR Rd,Rr 
O0|O0|1|0|1|0|r ddddd rrrr OR Rd,Rr 
001 ‘o LICEI | ddddd rrrr MOV Rd,Rr 
10 |:05] 1 | 0:10] ddddd 1)1)0 0  LD/STRdthroughX 
ANO |:0:] |: Dole ddddd 1)1)0 1 | |\LD/STRdthroughX+ 
ANILOrN|GOH] | 0,//Dalte ddddd 1 | 1)1 0 LD/STRdthrough-X 
TOO] do) 0) ddddd 1|)1]|1 1 |POP/PUSHRd 
| 1-operand instructions: 
000 | COM 
0|0|{1 NEG 
Delia h0 | SWAP 
| 00004] 0] 0 ddddd 0 | | 
0:1:1|:4 INC 
E 09 | ASR 
1|1|0 LSR 
1 | IA109 ROR 
0.4 | 1 |-® aa ddddd aaaa IN/OUT to I/O space 


Figura E.17 Esempio del formato di alcune istruzioni AVR. | campi ddad e rrrr identificano i registri 
coinvolti (Addd è di norma il registro di destinazione, eccetto le istruzioni ST dove fa da sorgente; 
aaaa identifica la porta di i/o. 
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COPROCESSORI 


E.7 | coprocessori 


Un coprocessore è un dispositivo usato per espandere la funzionalità del processore 
di base. Esempio classico è il coprocessore per calcoli in virgola mobile, denominato 
usualmente FPU (Floating Point Unit). 

Quando ancora non esistevano i microprocessori e la logica era fatta a partire da 
componenti discreti, era abbastanza comune avere coprocessori in forma di piastre elet- 
troniche, da inserire eventualmente sul bus di sistema, in grado di fornire le funzionalità 
aggiuntive. Di norma, nella configurazione di base, i sistemi di elaborazione non diretta- 
mente orientati al calcolo scientifico non prevedevano unità FPU. La configurazione di 
base poteva essere estesa, anche in tempi successivi all’acquisto, con l'aggiunta della FPU 
(a volte detta Arithmetic Accelerator). In mancanza di FPU, questa veniva emulata at- 
traverso una libreria software, che, ovviamente, si appoggiava sulle operazioni tra interi, 
per fornire le operazioni in virgola mobile in una qualche forma di sottoprogramma. In 
genere, si faceva in modo che l’assenza della FPU risultasse trasparente al programmato- 
re, il quale scontava solo tempi più lunghi, ma, almeno per quanto attiene alla scrittura 
dei programmi, non aveva da tener conto di altro. Ovvero l’assenza/presenza del copro- 
cessore era “trasparente” al programmatore. I criteri per ottenere la trasparenza sono 
discussi al paragrafo E.7.2. 

Con l’avvento dei primi microprocessori a 8 bit, vennero prodotte, in forma di singolo 
integrato, svariate unità aritmetiche, che, però, erano viste dalla CPU come un qualun- 
que periferico esterno. Il programmatore era responsabile della loro gestione diretta, 
trasmettendo loro comandi e dati e, successivamente, leggendo lo stato e i risultati delle 
operazioni comandate. Con un tale funzionamento era persa la trasparenza. Un esempio 
di questi dispositivi era l’integrato 8232, normalmente usato con le CPU 8080/8085. 

Con i microprocessori a 16 bit si cercò di ritornare alla trasparenza. All’epoca, le 
tecnologie dei circuiti integrati erano molto lontane dagli standard attuali. Non potendo 
integrare nella CPU la parte di logica per le operazioni in virgola mobile, i progettisti 
pianificarono l’uso dei coprocessori come dispositivi separati dalla CPU, ma in grado 
di estenderne le capacità, in modo tale che per il programmatore l'accoppiata CPU- 
coprocessore apparisse come un unico dispositivo — in grado di eseguire operazioni non 
disponibili per la sola CPU. I principali costruttori (Intel, Motorola e altri) seguirono 
questa strada. In particolare Intel introdusse il coprocessore 8087, indicato anche gene- 
ricamente come NPX (Numerical Processor eXtension) o anche NDP (Numerical Data 
Processor). Il coprocessore era dotato di registri interni di 80 bit, più di quanto richiesto 
dallo standard IEEE per l’aritmetica in doppia precisione. Tale è rimasta la dimensione 
dei registri anche quando il coprocessore è stato integrato nello stesso chip della CPU. La 
rappresentazione interna essendo su 80 bit, i numeri vengono automaticamente convertiti 
ai formati standard quando c’è scambio con l’esterno. 

Il coprocessore 8087 veniva montato direttamente sul bus della CPU, con la quale 
scambiava alcuni segnali di controllo ai fini del coordinamento delle operazioni!?. A par- 


121’8087 poteva essere impiegato direttamente sia con 1’8086/88, sia 1’80186/188. Nel seguito l’Intel 
sviluppò i coprocessori 80287 e 80387, in riferimento alle CPU 80286 e 80386. Altri produttori (tra essi 
Weitek) immisero sul mercato coprocessori aritmetici, diversi dall’8087, ma compatibili con l’architettura 
x86. 
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tire dal 486 l’unità in virgola mobile è integrata su tutte le CPU x86 e quindi, almeno 
per la categoria di macchine normalmente usate nei sistemi di calcolo (PC, workstation, 
server, ecc), i coprocessori tradizionali, cioè estensioni della CPU, hanno perso rilevanza 
pratica. In tale ambito ha invece preso campo l’impiego di un altro genere di “copro- 
cessori”. Ci riferiamo alle GPU impiegate ai fini dell’elaborazione numerica (Capitolo 11 
del libro). Esse costituiscono una classe specializzata di processori, costruiti per essere 
impiegate a qualsivoglia CPU e comunicanti con quest’ultima attraverso bus standard 
come il PCIe. 

Al contrario, nel campo dei sistemi embedded si fa ancora ampio uso di coprocessori. 
Per questo motivo, più avanti si fa riferimento al modo in vengono usati i coprocessori 
nell’architettura ARM, che nel settore dei sistemi embedded (dispositivi mobili e appli- 
cazioni industriali) fa la parte del leone. Prima però vengono illustrati i principi generali 
di funzionamento. 


E.7.1 Coordinamento con la CPU 


Per definizione, un coprocessore (COP) è un dispositivo che non fa il fetch delle 
istruzioni, ma che osserva sul bus il flusso delle istruzioni prelevate dalla CPU e interviene 
quando l’istruzione appartiene al proprio repertorio. Si faccia riferimento al semplice 
schema di Figura E.18. Schematicamente il funzionamento si basa sui seguenti criteri. 


a) il repertorio di istruzioni del COP è disgiunto da quello della CPU; 

b) la sola CPU è responsabile del prelievo (fetch) e della sequenzializzazione delle istru- 
zioni; 

c) dalle informazioni di stato disponibili sul bus il coprocessore riconosce i cicli fetch ed è 
in grado di riconoscere il codice dell’istruzione che sta passando sul bus dati; 

d) il coprocessore che riconosce che sta transitando sul bus un’istruzione del suo repertorio 
la preleva e la esegue; 

e) in presenza di un’istruzione del repertorio del coprocessore, la CPU attende che il co- 
processore abbia finito. Successivamente, procede con il fetch della prossima istruzione 
del programma. 


Figura E.18 Modello semplificato per lo studio del funzionamento di un coprocessore. CPU e COP 
sono sullo stesso bus. La prima è responsabile del flusso di informazioni sul bus, il secondo è in grado 
di catturare le informazioni di suo interesse che passano sul bus. 


La precedente schematizzazione è alquanto idealizzata, specialmente per quanto 
riguarda i punti c) e d). In particolare si deve tenere conto degli aspetti seguenti. 


e La CPU può funzionare in pipeline, dunque COP deve riprodurre al suo interno l’avan- 
zamento della pipeline, in modo da eseguire l’istruzione solo quando questa verrebbe 
effettivamente eseguita sulla CPU (se questa la eseguisse). Un’istruzione di salto che 
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preceda l’istruzione del coprocessore deve determinare lo svuotamento della pipeline 


anche in quest’ultimo. 


e Le istruzioni possono avere differente durata, dunque occorre un meccanismo di sin- 


cronizzazione tra CPU e COP. 
e A seconda del tipo di istruzione il comportamento di CPU e COP può variare. 


— Per le istruzioni che operano sui soli registri interni del coprocessore (ad esempio 


l'istruzione fadd f1,f2, che somma il contenuto dei due registri in virgola mobile 
f1 e £2 depositando il risultato in f1), poiché gli operandi dell’istruzione si trovano 
già nel coprocessore, COP è senz’altro in grado di effettuare l’operazione. 

Per le istruzioni che fanno accesso alla memoria (ad esempio l’istruzione fld f1,mem, 
che carica il f1 il contenuto di una posizione di memoria), il coprocessore non dispone 
dell’indirizzo; è quindi la CPU che deve indirizzare il dato in mem, come passo finale 
dell’esecuzione da parte sua dell’istruzione. 

C'è però da tenere conto del fatto che, in generale, il dato potrebbe essere di differente 
dimensione rispetto all’ampiezza del bus dati (ad esempio, il bus dati è a 32 bit, ma 
i numeri in virgola mobile sono a 64), dunque, alla lettura della prima porzione del 
dato, devono seguire tanti indirizzamenti a posizioni contigue a mem per portare il 
resto del dato nel coprocessore. Si potrebbe stabilire che è ancora la CPU a generare 
cicli di lettura di memoria, ma ciò non è conveniente perché il formato del dato 
è legato al codice di operazione e quindi è meglio che sia COP a stabilire quante 
letture di memoria ci sono ancora da fare per incamerare tutto il dato. Dunque, il 
coprocessore, oltre a incamerare la prima parte del dato, letta all’indirizzo mem dalla 
CPU, deve prendere traccia di tale indirizzo e successivamente usarlo per effettuare le 
letture della parte mancante. In conclusione, COP deve entrare in completo controllo 


del bus e ciò richiede un meccanismo di arbitraggio per l’accesso al medesimo!3. 


e Infine è conveniente che i codici di istruzione del coprocessore siano facilmente identi- 


ficati. Anche qui ci possono essere più modalità. 


— Prevedere che il codice delle operazioni del coprocessore siano precedute da un “pre- 


fisso” che la logica di CPU interpreta come istruzione non propria. Questa era la 
soluzione dell’8087, giustificata dal fatto le istruzioni x86 non hanno un formato 
regolare e un byte di prefisso (nel caso specifica il codice del carattere ESC) serve, 
anche in altri casi, a dare diversa interpretazione a quel che segue. 

Riservare uno o pochi codici di operazione per i coprocessori, salvo poi prevedere in 
altri campi dell’istruzione la specializzazione nella specifica operazione. Questa è la 
soluzione adottata nell’architettura ARM che prendiamo a campione qui di seguito. 


E.7.2 Il caso dei coprocessori ARM 


Le istruzioni dei coprocessori sono divise in tre classi 


a) istruzioni seguite direttamente dal coprocessore; 
b) istruzioni di trasferimento dati tra registri del coprocessore e registri della CPU; 
c) istruzioni di trasferimento tra registri del coprocessore e la memoria. 


In Figura E.19 vengono riportati i relativi formati. Le istruzioni ARM sono condi- 
zionali, ovvero vengono eseguite solo se al tempo di esecuzione è verificata la condizione 


13Queste complicazioni sono tipiche della macchine CISC, dove le istruzioni l’indirizzamento non sono 


regolari. Il coprocessore 8087 doveva sottostare a queste problematiche. 
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contenuta nel campo Cond, altrimenti l’istruzione equivale a un NOP. Per la discussione 
che segue il campo Cond può essere ignorato. 


31 28 27 24 20 16 14: 8 5 4 3 0 
a) Cond 1110 opc_1 crn CRd ID opc_2 |0| CRm 

31 28 27 24 21 20 16 12 8 5 4 3 0 
b) Cond 1110 |opc_i [LL CRn CRd ID opc_2 |1| CRm 

31 28 27 25 24 23 22 21 20 16 12 87 [o] 
Cc) Cond 110 PUNWL Rn CRd ID Offset 


Figura E.19 Formato delle istruzioni delle classi a), b) e c). Per le istruzioni della classe a) e b) il 
campo 27-24 contiene il codice primario di operazione 1110, il bit 4 discrimina tra le due classi; i campi 
opc_1 e opc_2 identificano la specifica operazione, mentre CRn, CRm e Ckd identificano i registri 
sorgente e il registro di destinazione. Per le istruzioni della classe c) il campo del codice primario di 
operazione è il 27-25 e vale 110, gli altri bit condizionano la sua intepretazione, in particolare il bit L 
discrimina le operazioni di Load da quelle di Store. Il campo ID contiene in ogni caso l'identificativo 
del coprocessore. 


In ogni istruzione è presente il campo ID di 4 bit in cui è codificato il numero del 
coprocessore cui l’istruzione si riferisce. Ne consegue che sono previsti fino a 16 coproces- 
sori, designati come CP0--CP15. Alcuni ID sono riservati per coprocessori che svolgono 
speciali funzioni. Per esempio, il coprocessore 15 (CP15) ha funzionalità di controllo del 
sistema; i coprocessori CP10 e CP11 sono riservati per le operazioni in virgola mobile, le 
operazioni vettoriali e le estensioni SIMD; altri ID sono riservati per usi futuri da parte 
di ARM; i rimanenti possono essere liberamente usati dall’utente per realizzare propri 
coprocessori. 

In linguaggio assembler, per tutte le istruzioni della classe a) si usa CDP ( Coprocessor 
Data Processing) come mnemonico del codice operativo, salvo precisare di quale specifica 
operazione si tratta. Per le istruzioni della classe b) si usano i mnemonici MRC (Move to 
Register from Coprocessor) e MCR (Move to Coprocessor from Register). Per le istruzioni 
della classe c) si usano i mnemonici LDC (Load Coprocessor) e STC (Store Coprocessor). 

Un paio di esempi chiariranno la sintassi del linguaggio assembler e come viene 
formattata l’istruzione. 


Esempi 
Istruzione della classe a). 


CDP{cond} p#,<espr1>,cd,cn,cm{,<espr2>} 


dove 
cond : mnemonico della condizione Cond; 
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p# :identificatore del coprocessore; 

espri: espressione valutata come costante e inserita nel campo opc_1; 

cd, cn, cm: tre campi valutati come numeri per i registri CRd, CRn e CRm; 
espr2: espressione opzionale, valutata come costante e inserita nel campo opc_12. 


Ad esempio 
CDP p1,10,c1,c2,c3 5 


CDPEQ p2,5,c7,c8,c9,2 ; 


Istruzione della classe c). 


<LDC|STC>{cond}{L} p#, 


COP 1 esegue l'operazione OP=10 

come CR1 <- OP(CR2, CR3) 

se il bit Z dello stato di macchina è 1 
COP 2 esegue l'operazione 5-2 

come CR7 <- OP(CR8, CR9) 


cd,<Indririzzo> 


dove 

cond : mnemonico della condizione Cond; 

p# :identificatore del coprocessore; 

L : se presente discrimina un trasferimento lontano o corto. Viene codificato nel 
campo N (non nel campo L che invece distingue Load da Store); 

cd: espressione il cui valore va nel campo CRd; 


Indirizzo: campo indirizzo (non staremo a illustrare tutte le possibilità). 


Ad esempio 
LDC pi,c2,tab 
STCNE p2,c3, [R5, #24]! 


; CRd <- mem[tab] 

i se il bit Z è 1 COP 2 memorizza 
; il contenuto del suo reg c3 

; in m[R5+24] (R5 è della CPU) 


Tipicamente un coprocessore contiene: 


e Una pipeline istruzioni (pipeline follower). 
e La logica di decodifica delle istruzioni. 


e La logica di handshake. 
e Un banco di registri. 


e La specifica logica di elaborazione delle istruzioni da esso trattate. 


Il coprocessore osserva le istruzioni di cui la CPU fa il fetch. Attraverso la pipeline 
follower, il coprocessore mantiene una pipeline identica a quella della CPU. (Un certo 
numero di segnali, che è inutile stare qui a descrivere, servono a mantenere la pipeline 
del coprocessore allineata con la pipeline della CPU.) 

Per la discussione che segue conviene riferirsi alla Figura E.20. 

La CPU partecipa all’esecuzione dell’istruzione del coprocessore. 


Specificatamente, la CPU: 


1. Determina se una istruzione deve essere eseguita da un coprocessore in base al codice 
primario di operazione; in caso affermativo asserisce il segnale CPI che, come mostra 
la Figura E.20, arriva a tutti coprocessori presenti. 
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Figura E.20 Segnali di handshake nel collegamento tra CPU coprocessori. teoricamente sono possibili 


fino a 16 coprocessori. CPI sta per Coprocessor Instruction, CPA per Coprocessor Absent; CPB per 
Coprocessor Busy. Se nessun coprocessore è presente, allora ambedue i segnali CPA e CPB devono 
essere tenuti alti. 


2. Genera gli eventuali indirizzi richiesti per la partecipazione del coprocessore all’ese- 
cuzione dell’istruzione; effettua il fetch della prossima istruzione per alimentare la 
pipeline. 

3. Genera una eccezione (trap) di istruzione non definita se, in presenza di una istruzione 
del repertorio dei coprocessori, non osserva basso il segnale CPA, ovvero se non è 
presente il relativo coprocessore. 


Dal canto suo, il coprocessore: 


1. Decodifica l’istruzione determinando se essa gli appartiene. 

2. Indica alla CPU attraverso i due segnali CPA e CPB se accetta l’istruzione. Come detto 
sopra, se nessun coprocessore risponde, si genera la “trappola” per codice non definito. 
Questa può essere eventualmente usata per emulare in software il coprocessore. 

3. Legge i propri registri interni che devono intervenire nell’esecuzione dell’istruzione 

4. Esegue l’operazione richiesta dall’istruzione stessa. 


Il coprocessore può portare CPA e CPB allo stato basso appena decodifica l’istruzio- 
ne, ma deve attendere che CPI sia asserito per eseguirla. Infatti è sempre possibile che 
l’istruzione sia preceduta da un salto condizionato e che debba essere scartata!”. Se il 
CPA resta alto si genera una eccezione per “istruzione non definita”; a quel punto sarà 
il software a prendere provvedimenti (per esempio, emulare il coprocessore). Se invece 
CPA è portato basso dal coprocessore, allora la CPU aspetta (busy form of waiting) 
che anche CPB sia portato basso, indicando che il coprocessore ha concluso l’operazione. 
(CPB resta basso per un solo periodo di clock.) 


1411 tempo che intercorre tra quando il coprocessore riconosce una propria istruzione e quello in cui CPI 
viene asserito può dipendere dallo stato della CPU e in certi casi può allungarsi di svariati cicli di clock. 
Per semplicità assumiamo che CPU e coprocessore siano allineati in modo che quando il coprocessore 
riconosce una istruzione del suo repertorio la CPU asserisca CPI nello stadio di esecuzione. In sostanza, 
stiamo dando una descrizione che trascura alcuni dettagli e complicazioni che possono sorgere. Una di 
queste è l’arrivo di una interruzione. 
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Per le istruzioni del gruppo a) la CPU si limita a riconoscerle e ad asserire CPI. L’o- 
perazione ha effetto solo sullo stato interno del coprocessore. Ad esempio, un’operazione 
di moltiplicazione in virgola mobile prende come argomenti il contenuto di due registri 
sorgente e deposita il risultato nel registro di destinazione. Il coprocessore segnala con 
CPB la conclusione dell’operazione; la CPU esce dall’attesa e procede con l’esecuzione 
della prossima istruzione quando vede CPB basso. 

Per le istruzioni del gruppo b), che determinano solo movimento dati, l’interazione 
tra CPU e coprocessore è immediata. 

Nel caso delle istruzioni del gruppo c), la CPU avvia l’inizio del trasferimento po- 
nendo l’indirizzo di memoria sul bus; il processore è responsabile della continuazione 
dell’operazione leggendo le parole richieste (la CPU può non conoscere le dimensioni dei 
dati trasferiti). 


La questione della trasparenza 
E’ stato detto che il programmatore dovrebbe poter impiegare il coprocessore in modo 
trasparente, nel senso che egli dovrebbe poter scrivere lo stesso codice, indipendentemente 
dal fatto che esso sia eseguito su macchina dotata o non dotata di coprocessore. Ciò viene 
ottenuto attraverso il meccanismo delle eccezioni. 

Consideriamo la generica istruzione di un coprocessore. 


e Se COP è presente esso interviene con i meccanismi sopra accennati 

e Se COP non è presente, si genera un’eccezione per “codice di operazione ignoto”, alla 
quale può essere associato un gestore che, in base alle informazioni di stato è in grado 
di individuare la specifica istruzione che ha determinato l’eccezione, ivi compresi i dati 
su cui essa opera, e chiamare una routine che ne simula il comportamento. 


Ovviamente, siccome il trattamento delle eccezioni è un compito del sistema opera- 
tivo, quest’ultimo deve essere configurato in modo tale che il trattamento dell’eccezione 
per codice ignoto sia congruente con l’obiettivo dell’emulazione del coprocessore. 


Osservazione conclusiva 

Nella parte che precede abbiamo illustrato il funzionamento dei coprocessori tradizionali, 
visti cioè come estensioni della CPU. Al Capitolo 11 del libro abbiamo illustrato come 
le GPU operino pure come “coprocessori”. Ma abbiamo anche rimarcato le differenze di 
funzionamento. 


E.8 Siti web 


Per i processori ARM è disponibile una vasta letteratura molto vasta , il lettore 
è inviato a riferirsi al sito principale https ://www.arm.com/, dove potrà navigare alla 
ricerca di ogni dettaglio circa i dispositivi ARM (non solo processori, ma anche dispositivi 
di corredo come controllori di interruzioni, o altro, incluse le specifiche del bus AMBA). 

Per i dispositivi prodotti da Atmel valgono considerazioni analoghe. Qui sono dispo- 
nibili singoli manuali, completi in ogni riguardo, sui differenti processori. 

Infine chi cercasse informazioni specifiche per il coprocessore 8087 di Intel è invitato 
a cercare nei siti indicati nella prefazione del libro. Ad ogni buon conto chi fosse solo 
interessato alle funzionalità aritmetiche esse si trovano descritte nei manuali correnti. 
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